In the field of automated systems, for example automated industrial systems such as manufacturing assembly lines or automotive control systems, a real-time distributed control system is often required in order for the systems to function effectively. In order to enable such real-time distributed control, a fieldbus is typically implemented to provide a real-time distributed communication mechanism between the various components that require the real-time distributed control. Fieldbus is the name of a family of industrial computer network protocols used for real-time distributed control, now standardized as IEC 61158. EtherCAT (Ethernet for Control Automation Technology) is an example of such a fieldbus network, and in particular comprises an Ethernet-based fieldbus network.
An important aspect of such fieldbus networks is their ability to provide real-time distributed control. In order to enable such real-time control, fieldbus networks such as EtherCAT networks rely on the synchronisation of the individual nodes within the system using a distributed clock mechanism, which enables the various slave nodes within the network to be synchronised within a common fieldbus time domain, and thus enables the fieldbus devices and their local applications to be synchronised to each other.
EtherCAT uses hardware within the slave nodes to synchronize the slaves to the master's time domain. Additionally, an EtherCAT ‘slave’ controller provides an interface between the EtherCAT fieldbus and a slave application. The master device is responsible for distributing frames with specific commands that slaves use to synchronize their clocks. The master device is not required to implement an EtherCAT specific hardware, and often such master devices comprise standard Ethernet controllers. As such, the master device is often located outside of the synchronised time domain of the EtherCAT system and may require specific algorithms to synchronize its time domain to the EtherCAT network.
The distributed clock system typically implemented within an EtherCAT system can synchronise all EtherCAT nodes to one reference clock. Typically, the first slave node with distributed clock capability after the master device, within a particular Ethernet network segment, is used to provide a reference time (system time) to which all other nodes within the system are synchronised. This system time is used as the reference clock in order to synchronise the local clocks of the other EtherCAT devices, and that of the master device. Propagation delays, local clock source drift and local clock offsets are taken into account for such clock synchronisation.
The clock synchronisation process typically consists of three stages:                1. Propagation delay measurement, where the master device initiates propagation delay measurement between all slave nodes in all directions by transmitting an ARMW (Auto increment physical Read Multiple Write) broadcast message. Each EtherCAT slave controller measures and saves locally the receive time of the measurement frame in each direction. The master device collects the receive times once the ARMW frame has travelled around the EtherCAT network and returned, and calculates the propagation delays between the slave nodes;        2. Offset compensation to reference clock (system time), where the local time of each slave clock is compared to the system time, and the difference compensated individually by writing to each slave. All devices are compensated to have the same absolute system time.        3. Drift compensation to Reference Clock, where the drift between the reference clock and local clock within each slave node is required to be compensated for by periodically measuring the differences between the two and readjusting the compensation therefor.        
Another requirement of many automated systems is availability/reliability of the system. Redundancy is one technique for increasing the reliability of a system, and in particular for increasing the availability of the system following a link failure. A proposed technique for providing redundancy within EtherCAT systems is a ring redundancy approach, such as illustrated in FIG. 1. In this known technique for providing redundancy within an EtherCAT system, an EtherCAT master device 110 is implemented with a master node 112 and two integrated EtherCAT slave nodes 114, 116. The EtherCAT network is arranged into a ring topology, with the EtherCAT master device 110 sending duplicate data packets in each direction around the ring (via each of the integrated slave nodes 114, 116). When a break occurs in the network, such as illustrated at 120, two independent EtherCAT line networks 140, 145 are created with each line network 140, 145 receiving a version of the (duplicated) data packets.
EtherCAT slave controllers are arranged to close an open port automatically if no device is detected on that port, and to forward frames on the next available port. Accordingly, upon a link failure 120 within the ring topology, the slave nodes 130, 135 either side of the break 120 close their respective ports and enable this ‘loopback’ functionality wherein frames will be looped back in the direction from which they came, creating two ‘out and back’ EtherCAT line networks 140, 145. Advantageously, because the EtherCAT master 110 sends duplicate data packets via each of the integrated slave nodes 114, 116, slave nodes within both of the line networks 140, 145 will continue to receive the data frames.
To minimise latency and jitter, EtherCAT slave nodes are arranged to process traffic only in one direction; all other directions of data flow within each slave node being limited to forwarding of the data. Thus, for a ring topology such as illustrated in FIG. 1, the slave nodes are typically orientated such that they process data travelling in the same direction. Accordingly, following a link failure 120, the direction of processing for the external slave nodes in one of the resulting line networks 140 will be towards the master device 110, whilst the direction of processing for the external slave nodes in the other resulting line network 145 will be away from the master device 110. In order to maintain synchronisation between the line networks, each of the integrated slave nodes 114, 116 is required to provide the distributed clock, and thus required to be the ‘first’ slave node within the respective line network 140, 145. Accordingly, for this known solution, the processing directions for the integrated slave nodes 114, 116 are structurally opposite to one another within the network ring in order to enable both of the integrated slave nodes 114, 116 to be ‘first’ in the respective line networks 140, 145 following a line break.
Due to the unidirectional processing performed by the slave nodes, the master device 110 is required to reconfigure the network topology upon link failure in order to take into consideration changes in the relative processing order of the slave nodes, and thus the addressing modes post link failure; in particular in relation to position addressing.
However, a transition from a ring topology to a dual-line topology has a significant impact on the synchronisation of the various nodes within the EtherCAT network. Whilst integrating the two slave nodes 114, 116 within the master device 110 enables a degree of synchronisation to be maintained between the two resulting EtherCAT line networks 140, 145, the master device 110 is required to re-calculate the propagation delays between the slave nodes within the new network topology. As it is not possible to know in advance where a link failure might occur, it is necessary to either re-calculate from scratch the new propagation delays after the link failure 120 occurs, which is time consuming and thus delays recovery from the link failure, or to calculate in advance propagation delay data for all possible scenarios, which not only adds complexity and delay to the initial propagation delay measurement process, but also requires memory space to store the propagation delay data and a more complex algorithm post link failure to redress synchronous behaviour. Since an EtherCAT network can comprise, in some examples, hundreds of slave nodes, it is clearly impractical to calculate and store propagation delay data for all possible scenarios.
In addition, the requirement for the master device 110 to duplicate packets and transmit them in two directions around the ring introduces more processing cycles, complexity and jitter into the transmission of data packets. For example, the master device 110 has to feed two transmit ports. It does this by sending the same packet on the two ports; either by duplicating the packet or handling two transmit queues. When the frames are looped back, the master device 110 also has to handle two receive flows, which increases the overall network complexity especially after a link failure. Specifically, the master device 110 has to know those slaves that are in each of the resulting line network paths 140, 145, and make sure that the processed elements of the frames are cognisant with regards to the current network topology. Accordingly, the master device 110 is required to perform a significant amount of additional checking.
Another limitation of this known approach to providing redundancy within an EtherCAT network is that it is only capable of supporting a ring topology, and thus only allows the deployment of slave nodes comprising two ports. Accordingly, it does not enable redundancy to be provided within more complex network topologies, such as tree topologies or the like.